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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 2/10/09 appealing from the Office action mailed 
7/11/08. 
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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

However, Appellant presumed that since the amendments after the final office action 
were entered, the 35 U.S.C. 112 second paragraph rejections presented in the previous office 
action was withdrawn. Examiner respectfully disagrees. 

The amendments were entered because it merely provided and/or corrected antecedent 
basis for the recited limitation. The 35 U.S.C. 112 second paragraph rejections still stands and 
have not been withdrawn. Moreover, examiner neither acknowledged nor indicated such a 
withdrawal. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 
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(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 
However, Appellant's has failed to address the 35 U.S.C. 1 12, 2 nd paragraph rejections presented 
in the Final office Action. This rejection stands as is. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

Thompson Michael I., EP 0572145 A2 published on Dec. 1, 1993. 
Scott, US 6,512,773 Bl, filed on Dec, 30, 1998, and issued on Jan. 28, 2003. 
Parruck et al, US 7,139,271 Bl, filed on Oct. 12, 2001, and issued on Nov. 21, 2006. 
Yik et al, US 6,697,873 Bl, filed on Aug. 22, 2000, and issued on Feb. 24, 2004. 



(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claim Rejections - 35 USC S 112 
The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

Claims 1-13 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

Independent claim 1 is reproduced herein: 

A network device configured to prevent data misalignment of a data packet containing extra header bytes, the network device 
comprising: 
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an ingress module having an input interface to receive a data packet comprising a plurality of cells wherein the a header cell of the 
data packet is one of the plurality of cells of the data packet, wherein the header cell of the plurality of cells comprises a header and packet data 
information and wherein the header cell includes the header in its entirety for the data packet ; 

a header detector configured to detect the header cell of the data packet and remove the header from the header cell of the data packet; 

a counter configured to determine whether the header cell of the data packet contains a multiple of a predetermined number of bytes 
after the header has been removed from the header cell; 

an insertion module configured to insert null bytes into the header cell of the data packet to form a modified header cell of the data 
packet if the counter determines that the header cell of the data packet does not satisfy the multiple of the predetermined number of bytes . . . ; and 

an extraction module configured to remove the null bytes from the modified header cell of the data packet as a modified cell of the 
data packet exits the network 



Applicant's Background Information discloses: 

[0004] A packet is a unit of data that is routed between a source and a destination network over the 
Internet or any other packet-switched network... when any tile (i.e. email message, html file...) is sent from.. .via the 
Internet, the TCP/IP may divide the file into packets... 

[0005] A packet, in general, loosely defines a block of variable-length data. Thus, packet switching 
scheme may be an efficient way to handle transmissions. ..In comparison, a cell, in the network terminology, is a 
fixed-length of data as opposed to variable-length of data. Cells are basic unit of data transport used in protocols, 
such as ATM. . . 



In light of these teachings, it is unclear whether the "data packet comprising plurality of 
cells, wherein a header cell of the data packet is one of the plurality of cells of the data packet, 
wherein the header cell of the plurality of cells comprises a header and packet data information 
and wherein the header cell includes the header in its entirety for the data packet" is with respect 
to data packets in packet switching environment, Ethernet OR ATM environment, which 
comprises cell-based switching environment, thus enabling the scope of the claim 
unascertainable. 



The teachings of packet-based receiving and cell-based receiving are distinct in the art, as 
evidenced by the applicant specification. 

More specifically, it is unclear whether the receiving is with respect to full data packet 
and/or data packet which are divided into cells and received as cells. 

Applicant is advised to take appropriate action. 

Claims 2-13 are rejected for the same reasons as set forth in claim 1. 
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Claim Rejections - 35 USC 8 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 1-4, 6-8 and 10-12 are rejected under 35 U.S.C. 103(a) as being obvious over 
Thompson, Michael I. (herein known as Thompson, EP 0 572 145 A2) in view of Scott (U. S. 
Patent No. 6,512,773 Bl), and further in view of Parruck et al. (hereinafter Parruck, U. S. Patent 
No. 7,139,271 Bl). 

As per claim 1, Thompson discloses a network device configured to prevent data 
misalignment of a data packet containing extra header bytes (col. 1 L25-38), the network device 
comprising: 

an ingress module having an input interface to receive the data packet, wherein the data 
packet comprises a header and packet data information (col. 1 L25-30, col. 1 1 L26-32, applicant 
admitted prior art, AAPA, pg. 4 [0008]); 

a header detector configured to detect a header of the data packet and remove the header 
from the data packet (col. 11 L51 to col. 12 L10, AAPA pg. 4 [0008]: conventional data packet 
includes one header for the entire data packet); 

an insertion module configured to insert null bytes into the header of the data packet to 
form a modified data packet if the CPU determines that the header/data split is not on an even 
byte boundary in order to align data packet (i.e. the number of bytes contained in data portion is 
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even, multiple of predetermined bytes is an even number or odd, and the alignment must be 
corrected by processor 15 by inserting null bytes into the header of the cell (col. 12 L28-36, col. 
1 L25-34; col. 5 L10-15, L29-37; fig 9; col. 4 L34-37: i.e. if the header/data split is not even, pad 
bytes or null bytes are inserted to correct the alignment)); and 

an extraction module configured to remove the null bytes from the modified header of the 
data packet as a modified data packet exits the network device (col. 6 L35-46). 

However, Thompson does not disclose a data packet comprising a plurality of cells, 
wherein a header cell of the data packet is one of the plurality of cells of the data packet and 
wherein the header cell of the plurality of cells comprises a header and packet data portion (i.e. a 
typical ATM environment, wherein the data packet is segmented into plurality of smaller pieces 
known as ATM cells) and a counter to determine whether the header cell of the data packet 
contains a multiple of a predetermined number of bytes after the header has been removed from 
the header cell. 

Scott discloses a network device comprising: an ingress module having an input interface 
to receive a cell of the data packet (col. 10 L15-21); an egress module having output interface to 
output the cells (col. 10 L27-30); a header detector configured to detect a header of the cell of the 
data packet and remove the header from the cell of the data packet (col. 10 L22-23, L54-55); a 
counter to determine and/or count the number of octets of the user data PDU of the payload; and 
an insertion module that adds pad characters to make the frame or cell equal an integer number 
of 48 octet cells in order to align cells of the data packet (i.e. inserting null bytes if the frame or 
cell does not satisfy an integer number of 48 octet i.e. if it does not satisfy the multiple number 
of the predetermined number of bytes, an even number, col. 10 L40-50, fig. 5C item #236). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Thompson in view of Scott, in order to include a counter that 
determines whether the cell of the data packet contains a multiple of a predetermined number of 
bytes after the header has been removed (i.e. a counter that counts number of bytes in the cell of 
the data packet), since Scott teaches and discloses a counter that counts data octets of the user 
data PDU of the payload and adding pad characters to make the frame equal an integer number 
of an even number of 48 octet cells. 

One of ordinary skilled in the art would have been motivated because it would have 
determined and/or counted the number of bytes in a cell (Scott, col. 10 L40-50) and based on the 
determination it would have inserted the pad byte into the cell in order to align the headers and 
the cell (Thompson, col. 1 L25-38). 

However, Thompson in view of Scott does not disclose a data packet comprising a 
plurality of cells including a header cell, wherein the header cell of the plurality of cells 
comprises a header and packet data information and wherein the header cell includes the header 
in its entirety for the data packet (please note: Scott inherently discloses the limitation because 
Scott is related to ATM networks, however, in order to establish a proper prima facie case, 
Parruck has been introduced). 

Parruck explicitly discloses a data packet comprising a plurality of cells, wherein the 
header cell of the data packet is one of the plurality of cells of the data packet, wherein the 
header cell of the plurality of cells comprises header and packet data information (col. 1 L64 to 
col. 2 L9, col. 11 L5-19, col. 17 L6-64, fig. 20, col. 25 L58 to col. 26 L43: i.e. Parruck discloses 
preventing misalignment in ATM networks, wherein ATM network is a cell-based routing 
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network and MPLS network), and wherein the header cell includes the header in its entirety for 
the data packet (fig. 41, col. 1 L64 to col. 2 L10, fig. 60J, 60H) [note that applicant's invention 
either utilizes packet switching scheme and/or cell-based switching scheme, and Parruck teaches 
both of these schemes or environment, e.g. col. 1 L26 to col. 2 L9, col. 4 L5-58). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Thompson in view of Scot and further in view of Parruck, in 
order to prevent misalignment in an ATM networks. 

One of ordinary skilled in the art would have been motivated because it would have 
prevented misalignment of the data packet and/or header cell in an ATM network (Parruck, col. 
30 L49 to col. 31 L17). 

As per claim 2, Thompson in view of Scott and further in view of Parruck discloses the 
network device wherein the network device comprises an aggregator that interfaces with an 
Ethernet and a SPI-4 system (Parruck, col. 31 L20-56, fig. 1, fig. 4, fig. 27). One of ordinary 
skilled in the art would have been motivated because of the same reasons as set forth in claim 1 . 

As per claim 3, Thompson in view of Scott and further in view of Parruck discloses the 
network device configured to interface between twelve 1 -gigabit ports and one 12 Gigabit/s SPI- 
4 interface (Parruck, col. 31 L20-56, fig. 1, fig. 4, fig. 27: please note the port speed and uplink 
speed may vary, however various modules are available with various speeds or bandwidth). One 
of ordinary skilled in the art would have been motivated because of the same reasons as set forth 
in claim 1 . 

As per claim 4, Thompson in view of Scott and further in view of Parruck discloses the 
system wherein the network device is a network switch (Parruck, fig. 2, fig. 4, fig. 9, col. 10 LI- 
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25). One of ordinary skilled in the art would have been motivated because of the same reasons as 
set forth in claim 1 . 

As per claim 6, Thompson further discloses forwarding the modified cell of the data 
packet to an output port (col. 6 L30-46). Therefore, claim 6 is rejected for the same reasons as set 
forth in claim 1 above. 

As per claims 7, 8 and 10-12, they do not teach or further define over the limitations in 
claims 1-4 and 6. Therefore, claims 7, 8 and 10-12 are rejected for the same reasons as set forth 
in claims 1-4 and 6. 

Claims 5, 9 and 13 are rejected under 35 U.S. C. 103(a) as being obvious over Thompson, 
Michael I. (herein known as Thompson, EP 0 572 145 A2) in view of Scott (U. S. Patent No. 
6,512,773 Bl), further in view of Parruck et al. (hereinafter Parruck, U. S. Patent No. 7,139,271 
Bl), and further in view of Yik et al. (U. S. Patent No. 6,697,873 Bl). 

As per claim 5, Thompson, Scott and Parruck disclose the network device comprising a 
layer two switching module configured to build a table of forwarding rules (Parruck, Parruck, 
fig. 2, fig. 4, fig. 9, col. 10 LI -25) and configured to instruct the extraction module to remove the 
null bytes from the modified cell of the data packet as the modified cell of the data packet exits 
the network device (Thompson, col. 6 L35-46; Parruck, col. 1 L64 to col. 2 L9, col. 11 L5-19, 
col. 17 L6-64, col. 25 L58 to col. 26 L43), however, Thompson, Scott and Parruck does not 
disclose a medium access control protocol module having a MAC address for transmitting the 
modified cell of the data packet and a layer two switching module configured to build a table of 
forwarding rules upon which the MAC addresses exist. 
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Yik explicitly discloses an apparatus comprising a medium access control protocol 
module having a MAC address for transmitting the modified cell of the data packet and a frame- 
forwarding device including MAC address tables (i.e. a layer two switching module building a 
forwarding table based on MAC addresses, see abstract, fig. 2, fig. 6, fig. 7A and col. 2L20-31, 
col. 4 L33-67). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to incorporate the teaching of Yik as stated above with Thompson, Scott 
and Parruck in order to include a MAC module for transmitting the modified cell of the data 
packet and a layer two switching module for building a forwarding table. 

One of ordinary skilled in the art would have been motivated because it would have 
increased the performance of the network by forwarding the frames to the correct output port 
associated with the particular MAC address (Yik, col. 2 L20-31). 

As per claim 9 and 13, they do not teach or further define over the limitations in claim 5. 
Therefore, claims 9 and 13 are rejected for the same reasons as set forth in claim 5. 
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(10) Response to Argument 

Examiner summarizes various issues and/or arguments raised by the appellant and 
addresses each of them separately. 

In the Appeal Brief (hereinafter The Brief), appellant argues in substance that: 
a. Applicant disagrees that Scott discloses determining whether the header cell of a 
data packet contains a multiple of a predetermined number of bytes after the header has 
been removed from the header cell, as recited in claim 1 (The Brief, pg. 14: l-2 nd 
paragraph, pg. 19, pg. 20). 

In response to argument [a], Examiner respectfully disagrees. 



Before addressing the appellant's arguments, A brief review of the prior art rejection, the 
prior art and the rationale for the combination is presented herein. 
Independent claim 1 recites: 

A network device configured to prevent data misalignment of a data packet containing extra header bytes, the network device 
comprising: 

an ingress module having an input interface to receive a data packet comprising a plurality of cells wherein a header cell of the data 
packet is one of the plurality of cells of the data packet, wherein the header cell of the plurality of cells comprises a header and packet data 
information and wherein the header cell includes the header in its entirety for the data packet; 

a header detector configured to detect the header cell of the data packet and remove the header from the header cell of the data packet; 

a counter configured to determine whether the header cell of the data packet contains a multiple of a predetermined number of bytes 
after the header has been removed from the header cell; 

an insertion module configured to insert null bytes into the header cell of the data packet to form a modified header cell of the data 
packet if the counter determines that the header cell of the data packet does not satisfy the multiple of the predetermined number of bytes . . . ; and 

an extraction module configured to remove the null bytes from the modified header cell of the data packet as a modified cell of the 
data packet exits the network 



Independent claim 1, 6 and 10 stands rejected as follows: 

As per claim 1, Thompson discloses a network device configured to prevent data misalignment of a data packet containing extra 
header bytes (col. 1 L25-38), the network device comprising: 

an ingress module having an input interface to receive the data packet, wherein the data packet comprises a header and packet data 
information (col. 1 L25-30, col. 1 1 L26-32, applicant admitted prior art, AAPA, pg. 4 [0008]); 

a header detector configured to detect a header of the data packet and remove the header from the data packet (col. 1 1 L5 1 to col. 12 
L10,AAPApg.4 [0008]); 

an insertion module configured to insert null bytes into the header of the data packet to form a modified data packet if the CPU 
determines that the header/data split is not on an even byte boundary (i.e. the number of bytes contained in data portion is even, multiple of 
predetermined bytes is an even number or odd, and the alignment must be corrected by processor 1 5 by inserting null bytes into the header of the 
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cell (col. 12 L28-36, col. 1 L25-34; col. 5 L10-15, L29-37; fig 9; col. 4 L34-37: i.e. if the header/data split is not even, pad bytes or null bytes are 
inserted to correct the alignment)); and 

an extraction module configured to remove the null bytes from the modified header of the data packet as a modified data packet exits 
the network device (col. 6 L35-46). 

However. Thompson does not disclose a data packet comprising a plurality of cells including a header cell, wherein the header cell of 
the plurality of cells comprises a header and packet data portion (i.e. a typical ATM environment) and a counter to determine whether the header 
cell of the data packet contains a multiple of a predetermined number of bytes after the header has been removed from the header cell. 

Scott, from the same field of endeavor discloses a network device comprising: an ingress module having an input interface to receive a 
cell of the data packet (col. 10 L15-21); an egress module having output interface to output the cells (col. 10 L27-30); a header detector 
configured to detect a header of the cell of the data packet and remove the header from the cell of the data packet (col. 10 L22-23, L54-55); a 
counter to determine and/or count the number of octets of the user data PDU of the payload; and an insertion module that adds pad characters to 
make the frame or cell equal an integer number of 48 octet cells (i.e. inserting null bytes if the frame or cell does not satisfy an integer number of 
48 octet i.e. if it does not satisfy the multiple number of the predetermined number of bytes, an even number, col. 10 L40-50, fig. 5C item #236). 

Therefore it would have been obvious to a person of ordinary skilled in the art at the time the invention was made to modify 
Thompson in view of Scott, in order to include a counter that determines whether the cell of the data packet contains a multiple of a 
predetermined number of bytes after the header has been removed (i.e. a counter that counts number of bytes in the cell of the data packet), since 
Scott teaches and discloses a counter that counts data octets of the user data PDU of the payload and adding pad characters to make the frame 
equal an integer number of an even number of 48 octet cells. 

One of ordinary skilled in the art would have been motivated because it would have determined and/or counted the number of bytes in 
a cell (Scott, col. 10 L40-50) and based on the determination it would have inserted the pad byte into the cell in order to align the headers and the 
cell (Thompson, col. 1 L25-38). 

However, Thompson in view of Scott does not disclose a data packet comprising a plurality of cells including a header cell, wherein 
the header cell of the plurality of cells comprises a header and packet data information and wherein the header cell includes header in its entirety 
for the data packet (please note: Scott inherently discloses the limitation because Scott is related to ATM networks, however, in order to establish 
the proper prima facie case, Parruck has been introduced). 

Parruck, from the same field of endeavor explicitly discloses a data packet comprising a plurality of cells including a header cell, 
wherein the header cell of the plurality of cells comprises header and packet data information, wherein the header cell includes the header in its 
entirety for the data packet (col. 1 L64 to col. 2 L9, col. 11 L5-19, col. 17 L6-64, col. 25 L58 to col. 26 L43: i.e. Parruck discloses preventing 
misalignment in ATM networks and MPLS network, fig. 41-42: Switch packet comprising switch header, i.e. header cell and plurality of data 
cells). 

Therefore it would have been obvious to a person of ordinary skilled in the art at the time the invention was made to modify 
Thompson in view of Scot and further in view of Parruck, in order to prevent misalignment in an ATM networks. 

One of ordinary skilled in the art would have been motivated because it would have prevented misalignment of the data packet and/or 
header cell in an ATM network (Parruck, col. 30 L49 to col. 31 L17). 



Thompson and The process of Preventing Data Misalignment 



Initially, Thompson discloses a network device configured to prevent data misalignment 



of a data packet containing extra header bytes (See col. 1 L25-38), as acknowledged by the 



appellant in the prosecution, E.g. See remarks filed 4/10/2008, pg. 11-12. 



Moreover, Thompson teaches the process of receiving a data packet having header and 



data portion, i.e. a typical Ethernet data packet, removing the header off the data packet and 



performing alignment of network header by inserting the pad or null bytes in the header to cause 



the header in the network packet to be aligned along predetermined multi-byte boundaries, i.e. 



adding pad bytes when it is determined that the header cell, i.e. cell does not satisfy the 



predetermined multi-byte boundaries (thus, resulting in a modified header) (col. 1 L25-54, col. 3 
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LI to col. 4 L50), as explicitly acknowledged by the appellant in the prosecution, See 
remarks filed 4/10/08, pg. 11-12. 

As indicated in the rejection, Thompson practices the invention in a network environment 
such as network 30 (col. 1 L25-54, fig. 2), which may be a typical Ethernet environment with 
Ethernet data packets. 

However, Thompson does not disclose the system wherein the network 30 is an ATM 
network, which is explicitly known to utilize cell-based routing of data packets. 

Parruck et al. and The ATM Network and/or protocol OR The Packet-switched 
network 

Parruck utilizes packet-switching and/or cell-based lower level protocol for transporting 
IP packets over a network, wherein the protocol is the Asynchronous Transfer Mode (ATM) (See 
col l L25-66), as acknowledged by the appellant in the prosecution, See remarks filed 
4/10/08, pg. 13, 2nd paragraph. 

In ATM, all packets are of equal length. They are therefore called "cells". A large IP 
packet is transported over an ATM network by segmenting the large IP packet into a 
plurality of smaller pieces, i.e. dividing the packets into plurality of cells. Each of smaller 
pieces is packaged to become an ATM cell. The ATM cells are then transported across the ATM 
network. When the ATM cells reach the edge of the ATM network, their payloads are 
reassembled to reform the large IP packet (Parruck, col. 1 L64 to col. 2 L10). 

An IP packet includes a single header for the entire data packet comprising plurality 
of cells as shown in the reproduced figure below, i.e. header in its entirety for the data packet. 
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For example: item #414, 417, 420 and 434 [See Also applicant's fig. 3A step #205 and 



210 for comparison purposes]. 



FIG. 40 
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FIG. 41 



At column 17 lines 5-64, Parruck discloses the process of receiving an ATM cell, 
wherein the ATM cell includes an ATM header 309 and a data payload 311. 

In other words, Parruck discloses a network device, such as a router/switch (fig. 1, fig. 2 
and fig. 4, col. 2 L37-57), wherein the data packet comprising plurality of cells are received, and 
wherein a header cell of the data packet is one of the plurality of cells of the data packet, i.e. 
header cell is equivalent to a cell of a data packet, and wherein the header cell of the plurality of 
cells comprises a header and packet data information, see col. 17 L6-64 and fig. 20, and wherein 
the header cell includes the header in its entirety for the data packet, for example: fig. 41 item 
#414 and 418. 

In other words, a switch packet, i.e. a data packet, comprises plurality of cells including 
the header cell in its entirety, i.e. a single header for the data packet comprising 64 byte cells. 
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Moreover, "a data packet comprising plurality of cells... wherein... wherein... and 
wherein..." is utilized in either ATM network and/or packet-switched network such as 
Ethernet, Fast Ethernet, etc., which are explicitly disclosed in the combination of Thompson and 
Parruck as set forth above [See Also, Applicant's Field of Invention [0002]]. 

Scott et al. and The Counter 

Thompson teaches and discloses the process of receiving a data packet having header and 
data portion, removing the header off the data packet and performing alignment of network 
header by inserting the pad or null bytes in the header to cause the header in the network packet 
to be aligned along predetermined multi-byte boundaries, i.e. adding pad bytes when it is 
determined that the header cell, i.e. cell does not satisfy the predetermined multi-byte 
boundaries. 

Stated another way, Thompson, initially, does suggest the usage of a counter that 
determines whether the header cell of the data packet contains and/or satisfies the predetermined 
multi-byte boundaries through the process of performing alignment of network header by 
inserting the pad or null bytes in the header to cause the header in the network packet to be 
aligned along predetermined multi-byte boundaries. 

Scott discloses a network device comprising: 

an ingress module having an input interface to receive a cell of the data packet (col. 10 
L15-21); 

an egress module having output interface to output the cells (col. 10 L27-30); 
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a header detector configured to detect a header of the cell of the data packet and remove 
the header from the cell of the data packet (col. 10 L22-23, L54-55); 

a counter to determine and/or count the number of octets of the user data PDU of the 
payload; and 

an insertion module that adds pad characters to make the frame or cell equal an integer 
number of 48 octet cells (i.e. inserting null bytes if the frame or cell does not satisfy an integer 
number of 48 octet i.e. if it does not satisfy the multiple number of the predetermined number of 
bytes, an even number, col. 10 L40-50, fig. 5C item #236). 

In other words, Scott teaches and discloses a counter as in claims 1-13. 

Modification and/or Rationale for the combination 

By applying the combination of Thompson and Scott to a system and network as in 
Parruck, i.e. applying Thompson and Scott to a network environment such as ATM 
network/protocol and/or to a packet-based switching environment, the combination would result 
in a process of inserting null bytes into the header cell including header in its entirety for the data 
packet to form a modified header cell of the data packet if the counter determines that the header 
cell of the data packet does not satisfy the multiple of the predetermined number of bytes and 
removing the null bytes from the modified header cell of the data packet as a modified cell of the 
data packet exists the network device. 

See KSR International Co. v. Teleflex Inc., 550 U.S. , , 82 USPQ2d 1385, 

1395-97 (2007) identified a number of rationales to support a conclusion of obviousness which 
are consistent with the proper "functional approach" to the determination of obviousness as laid 
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down in Graham. The key to supporting any rejection under 35 U.S.C. 103 is the clear 
articulation of the reason(s) why the claimed invention would have been obvious. The Supreme 
Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be made 
explicit, and MPEP 2143. [ EXEMPLARY RATIONALES: 

Exemplary rationales that may support a conclusion of obviousness include: 

(A) Combining prior art elements according to known methods to yield predictable results; 

(B) Simple substitution of one known element for another to obtain predictable results; 

(C) Use of known technique to improve similar devices (methods, or products) in the same way; 

(D) Applying a known technique to a known device (method, or product) ready for improvement to yield 
predictable results; 

(E) "Obvious to try" - choosing from a finite number of identified, predictable; 

(F) Known work in one field of endeavor may prompt variations of it for use in either the same field or a different 
one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the 
art; 

(G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify 
the prior art reference or to combine prior art reference teachings to arrive at the claimed invention. See MPEP § 
2143 for a discussion of the rationales listed above along with examples illustrating how the cited rationales may be 
used to support a finding of obviousness ]. 



In the Brief, for example: pgs. 14-15, appellant asserts that: 

"Column 10, lines 40-50 of Scott discloses: 



"(i)n block 231, the payload (105a of FIG. 4A) is processed from the frame 100. The number of 
octets of the user data PDU 71 of the payload is counted in block 232. This value forms the length field 
of the AAL5 CS. Note that the user data PDU 71 is the field found after the 4-octet ATM header field 
91 of FIG. 4A. Block 234 forms the W and CPI fields of the AAL5 frame. For the case where the UU and 
CPI field are not included in the header or trailer, the default "0" is used. Block 236 adds pad characters 
to make the AAL5 frame equal an integer number of 48 octet cells. In block 237, the 32 bit cyclic 
redundancy check (CRC) of the AAL5 frame is calculated. Block 238 segments the above AAL5 frame 
into an integer number of 48 octet cells." 



As can be clearly observed from column 10, lines 40-50 of Scott the only part of the frame 100 that is 
"counted" is the "User Data PDU" (i.e,. 71) portion of the payload 105a. In other words, the "4 octet ATM 
header" (i.e., 91) is not part of the counting operation performed by Scott. The only counting performed in 
Scott is counting on the number of octets of the user data included in the payload 71. The number of octets is 
used for the length field of the ATM adaptation layer-5 convergence sub-layer (AAL5 CS). The counting of the 
data octets in the payload is again reinforced in operation 232 of FIG. 5C. Once the segmentation of the 48 octet 
cells of data are prepared, then the 4 octet ATM header is extracted from the frame and HEC is added to create the 5 
octet ATM header. The 5 octet ATM header is then combined with the 48 octet payload to create a conventional 53 
octet ATM cell (operation 244). 
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Scott does not disclose using a counter to determine whether the header cell of the data packet 
contains a multiple of a predetermined number of bytes after the header has been removed from the header 

cell. The only operations that Scott performs after the header is extracted in operation 239 of FIG. 5C is adding the 
HEC to the header, adding the header back to the 48 octet payload, and appending a "last cell indicator" for the last 
cell (see operations 239- 244 of FIG. 5C). Therefore, Scott does not disclose or suggest "a counter configured to 
determine whether the header cell of the data packet contains a multiple of a predetermined number of bytes after 
the header has been removed from the header cell," as recited, in part, in independent claim 1 and similarly in 
independent claims 6 and 10." 
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Initially, appellant clearly admits that Scott's counter counts the User PDU portion 
of the payload 105a, i.e. section 71 of the following figure. 



Header 104a 



Usnr Ikrta PTIU 



Fig, 4A 



In other words, the counter determines whether the User Data PDU section of the packet, 
i.e. section 71 of the packet contains the multiple of predetermined number of bytes, in this case, 
48 octets, which is a multiple of predetermined number of bytes, obtained from AAL5 frame 
indication, and in an event the User Data PDU is not 48 octet payload, block 236 adds pads 
characters to make AAL5 frame equal an integer number of 48 octet cells. 

Scott further discloses: 
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In other words, the total frame size, i.e. cell size, must be an even multiple of 48 Octets. 
In order to achieve the even multiple of 48 Octets, the counter, as set forth above, counts the 
PDU portion of the packet to determine whether the PDU portion is equal to even multiple of 48 
Octets or is equal to 48 octets. In an event the PDU portion is not equal to even multiple of 48 
octets, the insertion module adds the pad characters to the PDU. 

However, appellant asserts that Scott odes not disclose using a counter to determine 
whether the header cell of the data packet contains a multiple of a predetermined number of 
bytes after the header has been removed from the header cell. 



Claim Construction for the argued limitation 

The claim, in part, recites: 

". . .where the header cell comprises a header and packet data information. . ." 

"...a counter... to determine whether the header cell of the data packet contains a 
multiple of a predetermined number of bytes after the header has been removed from the 
header cell..." 
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In other words, the functionality discloses a counter which is configured to 
determine whether the remaining portion of the header cell, i.e. packet data information, 
contains a multiple of a predetermined number of bytes after the header has been removed 
from the header cell. 

Stated another way, the counter counts the packet data information, similar to Scott's 
counter counting the user data PDU, left after the header has been removed from the header cell. 
As such, Scott does teach and disclose the counter as in claim 1. 

In the Brief, for example: pg. 16, appellant asserts that: 

"Furthermore, advisory action... Instead, the advisory action states... However, this is no 
more than another admission that Scott does not, in fact, count the header cell of any packet 
disclosed therein. . ." 

In response to appellant's assertions, Examiner disagrees merely because appellant 
is misinterpreting the examiner's obviousness analysis. 

Examiner's analysis was to show the appellant that if the counter in Scott can count the 
user pdu portion of the data packet to determine whether the packet contains a multiple of 48 
octets, then the counter can be adopted, for counting the header cell after the header has been 
removed, i.e. the remaining data portion, in order to determine whether to add the pad characters 
or not. 
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b. The rejection falls short of establishing a prima facie case of obviousness (The 
Brief, pg. 17). 

In response to argument [b], Examiner respectfully disagrees. 
In the Brief, for example, pg. 17, appellant asserts that: 

"...In the latter case, a proper rejection would need to provide an explanation of 
why, for example, one of ordinary skill in the art would have used the counter of Scott in 
a manner that is admittedly not disclosed in Scott and in a way that the counter is, at best 
"capable of being used. 

It appears appellant is arguing that there is no reason, suggestion and/or motivation for 
the combination. 

In response to appellant's argument that there is no suggestion to combine the references, 
the examiner recognizes that obviousness can only be established by combining or modifying the 
teachings of the prior art to produce the claimed invention where there is some teaching, 
suggestion, or motivation to do so found either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 
USPQ2dl596 (Fed. Cir. 1988) and In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 
1992). 

In this case, as explicitly acknowledged by the appellant, one of ordinary skilled in the art 
would have been motivated because it would have aligned the data packets and/or cells by 
counting the remaining portion of the cell or packet after the header has been removed, and 
inserting the pad bytes when its determined that the remaining portion is not a multiple number 
of bytes (See Scott: col. 10 L40-50 and Thompson: col. 1 L25-38). 
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The rationale and/or "explanation of why one of ordinary skill in the art would have used 
the counter of Scott in a manner. . ." as argued by the appellant can be found in KSR Ruling. 

See KSR International Co. v. Teleflex Inc., 550 U.S. , , 82 USPQ2d 1385, 

1395-97 (2007) identified a number of rationales to support a conclusion of obviousness which 
are consistent with the proper "functional approach" to the determination of obviousness as laid 
down in Graham. The key to supporting any rejection under 35 U.S.C. 103 is the clear 
articulation of the reason(s) why the claimed invention would have been obvious. The Supreme 
Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be made 
explicit, and MPEP 2143. [ EXEMPLARY RATIONALES: 

Exemplary rationales that may support a conclusion of obviousness include: 

(A) Combining prior art elements according to known methods to yield predictable results; 

(B) Simple substitution of one known element for another to obtain predictable results; 

(C) Use of known technique to improve similar devices (methods, or products) in the same way; 

(D) Applying a known technique to a known device (method, or product) ready for improvement to yield 
predictable results; 

(E) "Obvious to try" - choosing from a finite number of identified, predictable; 

(F) Known work in one field of endeavor may prompt variations of it for use in either the same field or a different 
one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the 
art; 

(G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify 
the prior art reference or to combine prior art reference teachings to arrive at the claimed invention. See MPEP § 
2143 for a discussion of the rationales listed above along with examples illustrating how the cited rationales may be 
used to support a finding of obviousness ]. 



For example: In this case, Scott and Thompson provide an explicit suggestion and/or 
motivation as set forth above. Rationale A, C and D also applies. 
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c. Further, as. . .the rejection fails further because Thompson explicitly teaches away 

the proposed combination (The Brief, pg. 19). 

In response to argument [c], Examiner respectfully disagrees. 

In the Brief, for example: pg. 18, appellant asserts: 

"Thompson discloses... However, in the very next paragraph, Thompson further 
discloses... based on the value of the destination service access point, the network adaptor 
places a number of pad bytes in the network link header... Thus, Thompson specifically 
discloses that the insertion of pad bytes within a header is based on a destination address 
of the header. Such a disclosure... teaches away... from the proposed modification of 
using the counter. . . " 

First, the referred very next paragraph is in the "Summary of the Invention". 



Application/Control Number: 09/982,794 Page 25 

Art Unit: 2451 

Secondly, it appears that appellant is misinterpreting the rejection, the modification 
and/or the prior art. 

As noted by the appellant, "the hardware in Thompson will insert between 0 and 3 pad 
bytes. . .based on the value found in the destination SAP field. . ." 

In other words, Thompson discloses using the destination address of the header to first 
determine the destination protocol, and then determining the number of pad bytes to add in 
order to align the cell or packet according to the destination. 

Initially, Thompson discloses that the network adaptor performs three operations, e.g. col. 
3 L34 to col. 4 L42. It should be noted that the second operation involves counting. The counting 
must be performed initially to determine how many bytes are contained in the remaining portion 
of the data packet or cell. 

For example: In an event the destination protocol requires frame size of 48. The hardware 
determines this size number and based on the number of octet in the frame, the hardware will 
determine the number of pad bytes to add. 

Moreover, Thompson does not criticize, discredit, or other wise discourage the 
usage of counter to count the remaining portion of the packet. See MPEP 2141 .02 (VI) and In re 
Fulton, 391 F.3d 1195, 1201, 73 USPQ2d 1141, 1146 (Fed. Cir. 2004) [However, "the prior art's 
mere disclosure of more than one alternative does not constitute a teaching away from any of 
these alternatives because such disclosure does not criticize, discredit, or otherwise discourage 
the solution claimed. . . ."]. 
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As such, the modification will not and does not render prior art unsatisfactory for its 
intended purpose. Stated another way, Thompson-Scott-Parruck will still operate to align the 
headers and/or data packets by inserting the pad bytes in the data packets. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 

Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 

Respectfully submitted, 

Kamal Divecha 
Art Unit 2451 
/John Follansbee/ 

Supervisory Patent Examiner, Art Unit 245 1 

Conferees: 

/John Follansbee/ 

Supervisory Patent Examiner, Art Unit 245 1 
/William C. Vaughn, Jr./ 
Supervisory Patent Examiner, Art Unit 2444 



